Throttling PostgreSQL's CPU usage - Mailing list pgsql-performance

From Daniel Griscom
Subject Throttling PostgreSQL's CPU usage
Date
Msg-id p0624080bc266892a91b2@[192.168.1.8]
Whole thread Raw
Responses Re: Throttling PostgreSQL's CPU usage  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Re: Throttling PostgreSQL's CPU usage  (Bill Moran <wmoran@collaborativefusion.com>)
Re: Throttling PostgreSQL's CPU usage  (david@lang.hm)
Re: Throttling PostgreSQL's CPU usage  (Mark Lewis <mark.lewis@mir3.com>)
List pgsql-performance
I'm building a kiosk with a 3D front end accessing PostGIS/PostgreSQL
via Apache/PHP. The 3D display is supposed to show smooth motion from
location to location, with PostGIS giving dynamically updated
information on the locations. Everything runs on the same machine,
and it all works, but when I start a query the 3D display stutters
horribly. It looks like PostgreSQL grabs hold of the CPU and doesn't
let go until it's completed the query.

I don't need the PostgreSQL query to return quickly, but I must
retain smooth animation while the query is being processed. In other
words, I need PostgreSQL to spread out its CPU usage so that it
doesn't monopolize the CPU for any significant time (more than 50ms
or so).

Possible solutions:

1: Set the PostgreSQL task priority lower than the 3D renderer task,
and to make sure that the 3D renderer sleep()s enough to let
PostgreSQL get its work done. The obvious objection to this obvious
solution is "Priority inversion!", but I see that as an additional
challenge to be surmounted rather than an absolute prohibition. So,
any thoughts on setting the PostgreSQL task priority (including by
the much-maligned tool shown at
<http://weblog.bignerdranch.com/?p=11>)?

2: Some variation of the Cost-Based Vacuum Delay. Hypothetically,
this would have the PostgreSQL task sleep() periodically while
processing the query, allowing the 3D renderer to continue working at
a reduced frame rate. My understanding, however, is that this only
works during VACUUM and ANALYZE commands, so it won't help during my
SELECT commands. So, any thoughts on using Cost-Based Vacuum Delay as
a Cost-Based Select Delay?

3: ... some other solution I haven't thought of.


Any thoughts, suggestions, ideas?


Thanks,
Dan

--
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: DISTINCT Question
Next
From: Charles Sprickman
Date:
Subject: Re: Best OS for Postgres 8.2